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Abstract. A simple mathematical definition of the 4-port model for pure 
Prolog is given. The model combines the intuition of ports with a compact 
representation of execution state. Forward and backward derivation steps 
are possible. The model satisfies a modularity claim, making it suitable for 
formal reasoning. 



1 Introduction 

In order to formally handle (specify and prove) some properties of Prolog execu- 
tion, we needed above all a definition of a port. A port is perhaps the single most 
popular notion in Prolog debugging, but theoretically it appears still rather elusive. 
The notion stems from the seminal article of L. Byrd [ByrSO] which identifies four 
different types of control flow in a Prolog execution, as movements in and out of 
procedure boxes via the four ports of these boxes: 

— call, entering the procedure in order to solve a goal, 

— exit, leaving the procedure after a success, i. e. a solution for the goal is found, 

— fail, leaving the procedure after the failure, i. e. there are no (more) solutions, 

— redo, re-entering the procedure, i. e. another solution is sought for. 

In this work, we present a formal definition of ports, which is a calculus of execution 
states, and hence provide a formal model of pure Prolog execution, S:PP. Our 
approach is to define ports by virtue of their effect, as port transitions. A port 
transition relates two events. An event is a state in the execution of a given query 
Q with respect to a given Prolog program U. There are two restrictions we make: 

1. the program U has to be pure 

2. the program 77 shall first be transformed into a canonical form. 

The first restriction concerns only the presentation in this paper, since our model 
has been prototypically extended to cover the control flow of full Standard Prolog, 
as given in [DEDC96] . The canonical form we use is the common single-clause rep- 
resentation. This representation is arguably 'near enough' to the original program, 
the only differences concern the head-unification (which is now delegated to the 
body) and the choices (which are now uniformly expressed as disjunction). 



2 Preliminaries and the main idea 



First we define the canonical form, into which the original program has to be trans- 
formed. Such a syntactic form appears as an intermediate stage in defining the 
Clark's completion of a logic program, and is used in logic program analysis. How- 
ever, we arc not aware of any consensus upon the name for this form. Some of the 
names in the literature are single-clausal form [Lin95] and normalisation of a logic 
program [KL02]. Here we use the name canonical form, partly on the grounds of 
our imposing a transformation on if-then as well (this additional transformation is 
of no interest in the present paper, which has to do only with pure Prolog, but we 
state it for completeness). 



Definition 1 (canonical form of a predicate) We say that a predicate P/n is 
in the canonical form, if its definition consists of a single clause P{Xi, ...,X„) : — 
B; Bs. Here i? is a "canonical body", of the form Xi=Ti, . . . , X„=r„, G, Gs, and 
P(Xi, Xn) is a "canonical head" , i. e. Xi, Xn are distinct variables not appear- 
ing in G, Gs, Tj , r„. Further, Bs is a disjunction of canonical bodies (possibly 
empty), Gs is a conjunction of goals (possibly empty), and G is a goal (for facts: 
true). Additionally, each if-then goal A ^ B must be part of an if-thcn-clsc (like 
A^B-Jail). ■ 

Example 1 (canonical form) For the following program 
q(a,b). 

q(Z,c) :- r(Z). 
r(c). 

we obtain as canonical form 

q(X,Y) :- X=a, Y=b, true; X=Z, Y=c, r(Z). 

r(X) X=c, true. □ 

Having each predicate represented as one clause, and bearing in mind the box 
metaphor above, we identified some elementary execution steps. For simplicity we 
first disregard variables. 

The following table should give some intuition about the idea. The symbols a, 
P in this table serve to identify the appropriate redo-transition, depending on the 
exit-transition. Transitions are deterministic, since the rules do not overlap. 
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—> call A 


exit A — "exit A; B fail A 
exit B — > ^ exit A;B fail B 


—> call B 
-> fail A;B 
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^redoA;B 


-t- redo A 
— 1> redo B 
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call true 


-^> exit true 






redo true - 


-> fail true 


fail 


call fs W - 


-> /ai/fail 













Table 1. The idea of port transitions 



Remark 1 (general goals) Observe that we extend the notion of a port, ini- 
tially conceived for predicates, to general goals. The shifting of attention from pred- 
icates to goals is the key idea of this approach. □ 

Notation 1 (distinguishing meta-level from object-level) In the follow- 
ing we show object-level terms (i. e. actual Prolog terms) in sans serif, like true. 
Meta-level terms (i.e. anything else in the calculus) will be shown in italics, like 
calljS, or in blackboard font, like □ 

Each transition pertains to a certain context, as indicated in Table 1. In the next 
step towards the new definition of ports we shall make this dependency explicit, by 
adding a parameter to each event. 

Example 2 (good, bad and main) Relative to the program 
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main :— good, bad. 
good. 

there are the foUowing execution steps for main: 

call main 

ca/Z (good, bad) -> 
call good — > 
call true — 1> 
exit true —> 
exit good — > 
call bad — > 
fail bad 
redo good —> 
redo true — > 
/aiZ true 
fail good —> 
fail (good, bad) —> 
fail main 

The indentations should suggest the context of the transitions, which is not very 
satisfying, since we want our representation to be entirely symbohc, and therefore 
visual aspects may not be part of the definition. So we provide the context infor- 
mation within the calculus, by means of a stack of ancestors, or A-stack. Hereby 
we define the immediate ancestor (the parent) of a goal to be the context of the 
transition. On some reflection, this is not enough. In case of a redo of an atomary 
goal, like redo true above, we need to know how the goal was resolved, in order to 
see the remaining alternatives. Since it is possible, in full Prolog, that a predicate 
definition changes between an exit and a redo, simply accessing the program would 
not guarantee the retrieval of the definition effective at the time of call. For this 
reason we memorize, at an exit of an atomary goal, the effectively used definition 
(more about this on page 6). Also, on exit from a disjunction, some kind of mcm- 
oing of the used disjunct is necessary. So we tried combining the memoing (both 
kinds of memos: used definitions and used disjuncts) with the administration of 
variable bindings, into one stack of bets, or B-stack. One claim of this paper is that 
an A-stack and a B-stack are sufficient to represent the execution of pure Prolog. As 
an illustration of the two-stack idea, let us show the above derivation in complete 
detail. In Appendix B an example with variables is given. Each stack is enclosed in 
parentheses, • separates the elements, and nil marks the bottom of a stack. 

call main, {nil}, {nil} 

call (good, bad) , {main»7ii/}, {nil} 
— > call good, {1/good, bad • main • ni/}, {nil} 

call true, {good • 1/good, bad • main • nil}, {nil} 
— > exit true, {good • 1/good, bad • main • ni?}, {nil} 

exit good , {1/good, bad • main • ni/}, {_BF(true, good) • ni^} 

call bad, {2/good, bad • main • ni/}, {_BF(true, good) • ni/} 

fail bad, {2/good, bad • main • ml}, {iJF(true, good) • niZ} 
-> redo good , {1/good, bad • main • nil}, {i?F(true, good) • niZ} 

redo true , {good • 1/good, bad • main • nil}, {nil} 

fail true, {good • 1/good, bad • main • nil}, {nil} 

fail good , {1/good, bad • main • nil}, {nil} 

fail (good, bad) , {main»7ii/}, {nil} 
—> fail main, {nil}, {nil} 

□ 
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3 The calculus S:PP 



We consider pure Prolog programs as given in Fig. 1, syntax domain "program", 
under restriction that every "definition" has to be in the canonical form. 

Definition 2 (event) An event is a quadruple {Port, Goal, A- stack, B- stack), as 
given by the grammar in Fig. 1, syntax domain "event". ■ 

Intuitively, an event is a state of Prolog execution, determined by four parameters: 

— port 

— current goal 

— history of current goal (stack of generalized ancestors, for short: A-stack) 

— current environment (stack of generalized bindings, bets, for short: B-stack) 

Definition 3 (transition rule) Let 77 be a program. Port transition rules wrt 7J 
are listed in Fig. 2. ■ 



event 

event 

definition 
program 
port 
goal 

ancestor 
tag 
memo 
bet 

stack of Xs 



, J / stack ot bets \ 

" * \ stack of ancestors ' 

port goal, {stack of ancestors}, {stack of bets} % inline 



= atom :— goal 

= {definition. }+ 

= call I exit \ fail \ redo 

= true I fail | atom | term= 

= true I fail | atom | term= 

= 7? F (goal, atom) 
= mgu I memo 
^ nil \ X • stack of Xs 



=term | goal;goal | goal, goal 

:term | tag/goal;goal | tag/goal, goal 



07?(goal, (tag/goal;goal)) 



Variables 
U, V 



a 

A, B, 

Ga 
T 



C, 



: stack of ancestors, 
: stack of bets, 
: substitution 
G, H : goal 
: atom 
: term 



U : ancestor 
S : bet 



Semantic functions 

Ti = T2 := Ti and T2 are identical 
<t(T') = application of a upon T 

mgu(T'i,Tg) = mgu of Ti and T2 

substOf(i;) = current substitution = composition of all mgus from 



substOf(m/)(T) := T 

f Z'(substOf(i:)(r)), if S is an mgu 
1 substOf(2:) ( T) , if is a memo 



substOf(i:«i:)(T) 



Syntactic domains that we do not redefine, but take in their usual sense: 
term (taken in the Prolog sense, as a superset of goal); 
atom (atomary goal in logic programming); 
substitution, mgu. 

Fig. 1. Language of events 
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Conjunction 



callA,B{fj) 



1/A,l 
E 


J.U 


\l A.l 
T 


J • V 


2/A,E 


;.(U 


2/ A, I 


; • V 



Disjunction 



exit A' 
fail A' 
exit B' 
Jail B' 

redo A, B (^) 

callA-B{f^) 

T 

./A;Bt 

fail B ( - 



exit B 



l/A-l 
T 




2/A;l 
T 


J • U 


l/A;l 
T 





call A I 

c«^^^"(27TOJ>' ^^^^ ^" 
faUA,B{^) 

exitA,B{^) 



call A { ^^^^g^^ ) 
callB { ^^^^g^J 
faUA;B{^) 



2jA~l 



exit A: B 



V 

■ OR(B,(2/A:B)) < 
V 



redoA;B{2^^i£^^^^ 



--) ^ redo C {j^j^g^} 



(S:conj:l) 
substOf(i:)(B) (S:conj:2) 
(S:conj:3) 
(S:conj:4) 
(S:conj:5) 
(S:conj:6) 



(S:disj:l) 
(S:disj:2) 
(S:disj:3) 
(S:disj:4) 
(S:disj:5) 
(S:disj:6) 



True 



call true (^) 
redo true (■^) 



ea;«i true (^) 
fail true (^) 



Fail 



callfaW (jj) -o failfaW • 



Explicit unification 

call Ti^T2 ifj) 
redoT,^T,{^) 
User-defined atomary goal Ga 

call Ga %) 

faUB{^) 
redo Ga (W^^) 



\exitTi = T2{^), ifmgvi{Ti,T2)^a 
j fail Ti^Tsifj), otherwise 

faUTi = T2{^) 



(S:true:l) 
(S:true:2) 



(S:fail) 

(S:unif:l) 
(S:unif:2) 



if _ff :— 5 is a fresh renaming of a 
mgu(G^,7; 
otherwise 



(callaiB){^) 

< clause in U, and mgu(G^,_ff) = a, and cr{GA) = Ga 

[faUGAi^), 

(S:atom:l) 

(S:atom:2) 

(S:atom:3) 

(S:atom:4) 



ex^t Ga (^m^) 
fatl Ga{^) 
redoB{j^) 



Fig. 2. Operational semantics S:PP of pure Prolog 



3.1 Remarks on the calculus 



About event: 

— Current goal is a generalization of selected literal: rather than focusing upon 
single literals, we focus upon goals. 

— Ancestor of a goal is defined in a disambiguating manner, via tags. 

— The notion of environment is generalized, to contain following bets: 

1. variable bindings, 

2. choices taken (OR-branches), 

3. used predicate definitions. 

Environment is represented by one stack, storing each bet as soon as it is com- 
puted. For an event to represent the state of pure Prolog execution, suffices here 
one environment and one ancestor stack. 

About transitions: 

— Port transition relation is functional. The same holds for its converse, if re- 
stricted on legal events, i. e. events that can be reached from an initial event of 
the form callG{^). 

— This uniqueness of legal derivations enables forward and backward derivation 
steps, in the spirit of the Byrd's article. 

— Modularity of derivation: The execution of a goal can be abstracted like for 

example call G {^) — > exit G {^jj^)- Notice the same A-stack. 

Remark 2 (atomary goal) By atom or atomary goal we denote only user-defined 
predications. So true, fail or Ti = T2 shall not be considered atoms. □ 

Remark 3 (mgu) The most general unifiers a shall be chosen to be idempotent, 
i.e. a(a(r)) =a(T). □ 

Remark 4 (tags) The names A' or B' of (S:conj:2)-(S:conj:5) should only suggest 
that the argument is related to ^ or B, but the actual retrieval is determined by the 
tags 1 and 2, saying that respectively the first or the second conjunct are currently 
being tried. For example, the rule (S:conj:l) states that the call of A,B leads to 
the call of A with immediate ancestor 1/A,B. This kind of add-on mechanism 
is necessary to be able to correctly handle a query like A, A where retrieval by 
unification would get stuck on the first conjunct. □ 

Remark 5 (canonical form) Note the requirement ct^Ga) = Ga in (S:atom:l). 
Since the clauses are in canonical form, unifying the head of a clause with a goal 
could do no more than rename the goal. Since we do not need a renaming of the 
goal, we may fix the mgu to just operate on the clause. □ 

Remark 6 (logical update view) Observe how (S:atom:2) and (S:atom:4) serve 
to implement the logical update view of Lindholm and O'Keefe [L087], saying that 
the definition of a predicate shall be fixed at the time of its call. This is further 
explained in the following remark. □ 

Remark 7 ("lazy" binding) Although we memorize the used predicate defini- 
tion on exit, the definition will be unaffected by exit bindings, because bindings 
are applied lazily: Instead of "eagerly" applying any bindings as they occur (e. g. in 
Ti = T2, in resolution or in read), we chose to do this only in conjunction (in rule 
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(S:conj:2)) and nowhere else. Due to the rules (S:conj:l) and (S:conj:4), the exit 
bindmgs shall not affect the predicate definition like e.g. p(X) :— q(X), r(X). 

Also, lazy bindings enable less 'jumpy' trace. A jumpy trace can be illustrated 
by the following exit event (assuming we applied bindings eagerly): 

exit append([0],B, [0|B]), {2/([l|B] = [l|B]), append([], B, B) . U}, T 

The problem consists in exiting the goal append([], B, B) via append([0], B, [0|B]), 
the latter of course being no instance of the former. By means of lazy binding, 
we avoid the jumpincss, and at the same time make memoing definitions on exit 
possible. To ensure that the trace of a query execution shows the correct bindings, 
an event shall be printed only after the current substitution has been applied to it. 

A perhaps more important collateral advantage of lazy binding is that a suc- 
cessful derivation (see Definition 11) can always be abstracted as follows: 

call Goal —> exit Goal 

even if Goal happened to get further instantiated in the course of this derivation. 
The instantiation will be reflected in the B-stack but not in the goal itself. □ 



4 Modelling Prolog execution 

Definition 4 (port transition relation, converse) Let 77 be a program. Port 
transition relation —> wrt U is defined in Fig. 2. The converse relation shall be 
denoted by <— . li Ei —> E, we say that Ei leads to E. An event E can be entered, 
if some event leads to it. An event E can be left, if it leads to some event. g 

Lemma 1 The relation — > is functional, i. e. for each event E there can be at most 
one event Ei such that E —> Ei. ■ 

Proof: The premisses of the transition rules are mutually disjunct, i. e. there are 
no critical pairs. □ 

Example 3 (converse relation) The converse of the port transition relation is 
not functional, since there may be more than one event leading to the same event: 

callT, = T,{^^) faUT,^T,{^) 
redoT.^T^i^) faU T,^T, {^) 

We could have prevented the ambiguous situation above and made converse relation 
functional as well, by giving natural conditions on redo-transitions for atomary goal 
and unification. However, further down it will be shown that, for events that are 
legal, the converse relation is functional anyway. □ 

Definition 5 (derivation) Let 77 be a program. Let Eq, E be events. A 77- 
derivation of E from Eq, written as Eq —<> 7?, is a path from Eq to E in the 
port transition relation wrt 77. We say that E can be reached from Eq. ■ 

Definition 6 (initial event, top-level goal) An initial event is any event of the 
form call Q{-^), where Q is a goal. The goal Q of an initial event is called a 
top-level goal, or a query. ■ 
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Definition 7 (legal derivation, legal event, execution) Let 77 be a program. 
If there is a goal Q such that 



call Q{'^^) ^ Eo ^ E 



is a 77-derivation, then we say that Eq —> E is a legal U-derivation, 7? is a legal 

I nil \ 
^ nil I 



U-event, and call Q {^) ~o Eq is a U-execution of the query Q. 



Definition 8 (final event) A legal event 7? is a final event wrt program 77, if 
there is no transition E —> Ei wrt 77. B 

Definition 9 (parent of goal) If 7? = Port G (^) is an event, and U = P»V, 
then we say that P is the parent of G. ■ 

Notation 2 (selector tags) Function Sel({7) is defined as follows: 

Sel((l/^,B)) Sel((2/^,5)) := B 

and analogously for disjunction. □ 

Definition 10 (push/pop event) Let E be an event with the port Port. If Port 
is one of call, redo, then 7? is a push event. If Port is one of exit, fail, then E is a 
pop event. ■ 

Lemma 2 (final event) If 7? is a legal pop event, and its A-stack is not empty, 
then 3Ei: E ^ El ■ 

Proof (sketch): According to the rules (see also Appendix A), the possibilities 
to leave an exit event are: 

exit ^'( i/^.B.u ) call B" i ^/A^B,^ ), with S" := substOf(I)(S) 
exits' ( ^^^^g^^j ) -> exitA,B(fj) 



exit 7? ( - , . p . ■ , ) — > exit A: B 



■ OR{B,{2/A;B)) i 



\2/A;B »V' \ y 

e^^iBi^) -> exUGAi^^^^^f^) 

These rules state that it is always possible to leave an exit event exit G {^), save for 
the following two restrictions: The parent goal may not be true, fail or a unification; 
and if the parent goal P is a disjunction, then there has to hold 

G = Sel(F) (1) 

i.e. it is not possible to leave an event exit A' ( ^y^.g^y ) if A' =^ A (and similarly 
for the second disjunct). The first restriction is void, since a parent cannot be true, 
fail or a unification anyway, according to the rules. It remains to show that the 
second restriction is also void, i. e. a legal exit event has necessarily the property 
(1). Looking at the rules for entering an exit event, we note that the goal part of 
an exit event either comes from the A-stack, or is true or Tj^Tg. The latter two 
possibilities we may exclude, because ea;if true (y/a^Tv) '^^^^ only be derived from 
caH true ( i/a^b » "^tiich cannot be reached if true / A. Similarly for unification. 
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So the goal part of a legal exit event must come from the A-stack. The elements 
of the A-stack originate from call/redo events, and they have the property (1). 
In conclusion, we can always leave a legal exit event with a nonempty A-stack. 
Similarly for a fail event. □ 

Proposition 1 (uniqueness) If is a legal event, then E can have only one legal 
predecessor, and only one successor. In case E is non-initial, there is exactly one 
legal predecessor. In case E is non-final, there is exactly one successor. ■ 

Proof: The successor part follows from the functionality of — > . Looking at the 
rules, we note that only two kinds of events may have more than one predecessor: 
fail Ga {^) and/aiZ Ti = T2 (^). het fail Ti = T2 (jj) be a legal event. Its predecessor 
may have been call Tj^Tg (^) , on the condition that and have no mgu (rule 
(S:umf:l)), or it could have been redo Ti = T2 (^) (rule (S:unif:2)). In the latter 
case, redo Ti = T2 {^-\^) must be a legal event, so the B-stack auIL had to be 
derived. The only rule able to derive such a B-stack is (S:unif:l), on the condition 
that the previous event was call Ti = T2 (^) and mgu(T'j,T2) = a. Hence, there 
can be only one legal predecessor of fail Ti = T2 (^), depending solely on Ti and 
T2. By a similar argument we can prove that fail Ga (■§) can have only one legal 
predecessor. This concludes the proof of functionality of the converse relation, if 
restricted to the set of legal events. □ 

Notation 3 (impossible event) As a notational convenience, all the events which 
are not final and do not lead to any further events by means of transitions with 
respect to the given program, arc said to lead to the impossible events written as 
_L. Analogously for events that arc not initial events and cannot be entered. In 
particular, redo fail — > 1. and exit faW <— ± with respect to any program. Some 
impossible events arc: call G (^-^^), redo G (^) (cannot be entered, non-initial), 
and redo p (^) (cannot be left, non- final). □ 

3); ^ 

Lemma 3 (non-legal event) U E ~o ±, then E is not legal. If <— ±, then E 
is not legal. ■ 

Proof: Let E <— i^i. If is legal, then, because of the uniqueness of the transition. 
El has to be legal as well. □ 

Lemma 4 (call is up-to-date) For a legal call event call G (^) holds that G ~ 
substOf(2!)(C?), meaning that the substitutions from the B-stack are already applied 
upon the goal to be called. In other words, the goal of any legal call event is up-to- 
date relative to the current substitution. ■ 

Notice that this property holds only for call events. 

Notation 4 (stack concatenation) Concatenation of stacks we denote by +. 
Concatenating to both stacks of an event we denote by j:: If £' = Port G {^), then 
Et{^) ■.= PoHG{f^). ' □ 

Proposition 2 (modularity of derivation) Let 77 be a program. Let Pop be 
one of exit, fail. If 

callGi^,) - - ... - i?„ - PopG{^) 
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is a legal 7T-derivation, then for every A-stack U and for every B-stack T such that 
call G {^) is a legal event, holds: 

call G %) - El X %) - ... -> i?„ \ %) - Pop G (^) 

is also a legal 7J-derivation. B 

Proof: Observe that our rules (with the exception of (S:conj:2)) refer only to the 
existence of the top clement of some stack, never to the emptiness of a stack. Since 
the top element of a stack S cannot change after appending another stack to S, it 
is possible to emulate each of the original derivation steps using the 'new' stacks. 

It remains to consider the rule (S:conj:2), which applies the whole current substi- 
tution upon the second conjunct. First note that any variables in a legal derivation 
stem either from the top-level goal or are fresh. According to the Lemma 4, a call 
event is always up-to-date, i. e. the current substitution has already been applied to 
the goal. The most general unifiers may be chosen to be idempotent, so a multiple 
application of a substitution amounts to a single application. Hence, if call G {^) 
is a legal event, the substitution of T cannot affect any variables of the original 
derivation. □ 

5 Applications 

5.1 Specifying program properties 

Uniqueness and modularity of legal port derivations allow us to succinctly define 
some traditional notions. 

Definition 11 (termination, success, failure) A goal G is said to terminate 
wrt program 7T, if there is a 7T-derivation 

callG{^) ^ PopG{^) 

where Pop is one of exit, fail. In case of exit, the derivation is successful, otherwise 
it is failed. ■ 

In a failed derivation, A = nil. 

Definition 12 (computed answer) In a successful derivation 

callGi^i) ^ exitG{A^) 

is substOf(A), restricted upon the variables of G, called the computed answer sub- 
stitution for G. ■ 

5.2 Proving program properties 

Uniqueness of legal derivation steps enables forward and backward derivation steps, 
in the spirit of the Byrd's article. Push events (call, redo) are more amenable to 
forward steps, and pop events (exit, fail) are more amenable to backward steps. We 
illustrate this by a small example. 

Lemma 5 If the events on the left-hand sides are legal, the following are legal 
derivations (for appropriate T^, Tt): 

exit A; B, fail (^) <- exit A { yA;B%;,^ ) (2) 

redo A; B, fail %) ^ redo A (^^^^l—.) (3) 
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Proof: The first statement claims: If exit A; B, fail (-p) is legal, then it was reached 
via exit A. Without inspecting T, in general it is not known whether a disjunc- 
tion succeeded via its first, or via its second member. But in this particular dis- 
junction, the second member cannot succeed: Assume there are some Do, with 
exit A; B, fail (fj) <— exit B, fail (^). According to the rules: 

exttBM\{f^) - fail (57^1^) - ± 

So according to Lemma 3, exit B,fa\\ {^) is not a legal event, which proves (2). 
Similarly, the non-legal derivation rerfo_B, fail —> redo fail _L proves (3). □ 

Modularity of legal derivations enables abstracting the execution of a goal, like 
in the following example. 

Example 4 (modularity) Assume that a goal A succeeds, i.e. call A {^) —> 
exit A {-^)- Then we have the following legal derivation: 

callA^Bi^^) - call A {^^^^^), by (S:conj:l) 

— > exit A { 'b^uU ) ' modularity and success of A 

ca;/B' (jj^^stm), by (S:conj:2), where B' = subst0f(A)(5) 

If A fails, then we have: 

callA,B{^) - callA{jjjf—j), by (S:conj:l) 

fail A ( i/aIs* nii ^^ modularity and failure of A 
^ by (S:conj:3) □ 



6 Conclusions and outlook 

In this paper we give a simple mathematical definition S:PP of the 4-port model of 
pure Prolog. Some potential for formal verification of pure Prolog has been outlined. 
There arc two interesting directions for future work in this area: 

(1) formal specification of the control flow of full Standard Prolog (currently we 
have a prototype for this, within the 4-port model) 

(2) formal specification and proof of some non-trivial program properties, like ade- 
quacy and non-interference of a practical program transformation. 

7 Related work 

Concerning attempts to formally define the 4-port model, we are aware of only few 
previous works. One is a graph-based model of Tobcrmann and Bcckstein [TB93], 
who formalize the graph traversal idea of Byrd, defining the notion of a trace (of 
a given query with respect to a given program), as a path in a trace graph. The 
ports are quite lucidly defined as hierarchical nodes of such a graph. However, 
even for a simple recursive program and a ground query, with a finite SLD-tree, 
the corresponding trace graph is infinite, which limits its applicability. Another 
model of Byrd box is a continuation-based approach of Jahicr, Ducassc and Ridoux 
[JDROO]. There is also a stack-based attempt in [KulOO], but although it provides 
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for some parametrizing, it suffers essentially the same problem as the continuation- 
based approach, and also the prototypical implementation of the tracer given in 
[ByrSO], taken as a specification of Prolog execution: In these three attempts, a 
port is represented by some semantic action (e. g. writing of a message), instead of 
a formal method. Therefore it is not clear how to use any of these models to prove 
some port-related assertions. 

In contrast to the few specifications of the Byrd box. there are many more gen- 
eral models of pure (or even full) Prolog execution. Due to space limitations we 
mention here only some models, directly relevant to S:PP, and for a more compre- 
hensive discussion see e.g. [KBOl]. Comparable to our work are the stack-based 
approaches. Stark gives in [Sta98], as a side issue, a simple operational semantics of 
pure logic programming. A state of execution is a stack of frame stacks, where each 
frame consists of a goal (ancestor) and an environment. In comparison, our state of 
execution consists of exactly one environment and one ancestor stack. The seminal 
paper of Jones and Mycroft [JM84] was the first to present a stack-based model of 
execution, applicable to pure Prolog with cut added. It uses a sequence of frames. 
In these stack- based approaches (including our previous attempt [KBOl]), there is 
no modularity, i. e. it is not possible to abstract the execution of a subgoal. 
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A Leaving events 



Leaving a call event 

callA,B{fj) 
call A; B (^) 
call true (■^) 
call faW (^) 

call Ti^Ts (f) 
call Ga ) 



Leaving a redo event 

redoA,B{fj) 

redo true (jj) 
redo Ti^T2 {^^) 
redo Ga (^m^) 

Leaving an exit event 



exit A' 
exit B' 



exit B 



1/A,l 
T 


3 • U 


2/A,l 
T 




l/A-l 
T 


3.(U 



2/A;B.(U/ 



Leaving a fail event 
fail A' 



l/A,B»Vi 
/««^ ^' ( 2/A,B.u ) 



(S:conj:l) 
(S:disj:l) 
(S:tmc:l) 
(S:fail) 



(S:unif:l) 



a/A;, 
exit true (^) 
/az?fail(f) 

Tj = r2(^), if mgu( , Tg) 
I Jail Ti^Tsi^), otherwise 

{call a (B) { Q^,^j ), if H B is a fresh renaming of a 
clause in 77, and mgu(G'^,77) = a, and cr(G^) = Ga 
fail Ga (^), otherwise 

(S:atom:l) 



redo B ijjj^-^) 
redoG{ j^/^^g,J 
fail true {fj) 
faUTi = T2{l) 
redoB{^) 



callB" { 2/A%,v )' ^it^ ^" 

exitA,B{^) 

ex»t^;7?( "^'^-(™>'^ ) 
exzt Ga (^m^) 



/azZ Ga{^) 



(S:conj:6) 
(S:disj:6) 
(S:truc:2) 
(S:unif:2) 
(S:atom:4) 



:= substOf(E)(S) (S:conj:2) 
(S:conj:4) 



(S:disj:4) 
(S:disj:5) 
(S:atom:2) 



(S:conj:3) 
(S:conj:5) 
(S:disj:2) 
(S:disj:3) 
(S:atom:3) 
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B An example with variables 



Assume the following program U: 

post(X,Y) :- one(X,Y), two(X,Y). 
one(X,_) :- X=l. 
two(.,Y) :- Y=a; Y=b. 

Table 2 below shows the complete 77-execution of the goal post(X, Y), fail in the model S:PP. Highlighted are the A-stacks and the mgus. Notice the 
"lazy" binding of variables in the current goal. 

call (post(X, Y),fail) , {nil} , {nil} 
-o caH post(X, Y) , {l/post(X,Y),fail»ni;} ■ 

call (one(X,Y),two(X, Y)) , {post(X, Y) • l/post(X, Y) , fail . nii} . {nil} 

can one(X,Y), {l/one(X, Y), two(X, Y) • post(X, Y) • l/post(X, Y) , fail • mi} , {mi} 
-o caHX=l, {one(X, Y).l/one(X,Y),two(X,Y).post(X,Y).l/po5t(X,Y),fail»nii} , {ml} 
-> cxitX=l, {one(X,Y).l/one(X,Y),two(X,Y).post(X,Y).l/po5t(X,Y),fai!.mi} , { |BBI *™U 

e2:2f one(X, Y) , {l/one(X, Y) , two(X, Y) • po5t(X, Y) • l/post(X, Y) , fail . nii} . {By(X=l, one(X, Y)) « |BBI » ™'> 

ca« two(l,Y). {2/one(X,Y),two(X,Y).post(X,Y)»l/post(X,Y),fail»n2i} , {By(X=l, one(X, Y)) » |BBI « ™U 

call (Y=a:Y=b), {two(l, Y) . 2/one(X, Y) , two(X, Y) . post(X, Y) . l/po5t(X, Y) , fail . nii} , {BY(X=1, one(X, Y)) «|5B|« mi} 



{(l/(Y=a); Y=b) « two(l, Y) . 2/one(X, Y), two(X, Y) • po5t(X, Y) > l/post(X, Y), fail • nil} 


, {BY{X= 


l,one(X, Y)) • 


[X/1] 


• 


nil} 




{(l/(Y=a); Y=b) .two(l, Y) .2/one(X, Y),two(X, Y) • post(X,Y) < l/po5t(X, Y) , fail . ni/} 




[Y/a] 


« BY(X=1 


,one(X, Y)) 


• 


IX/l] 


• nil} 



-o exit (Y=a;Y=b). {two(l, Y) • 2/one(X, Y), two(X, Y) . post(X, Y) . l/po5t(X, Y), fail • mi} , { 07?(Y=a, (l/(Y=a) ; Y=b)) . I^^l . B Y(X=1, one(X, Y)) • . mi} 

-o exit two(l, Y) , {2/one(X, Y),two(X, Y) •post(X, Y) • l/po5t(X, Y) , fail . mi} , {By((Y=a: Y=b), two(l, Y)) > Ofl(Y=a, (l/(Y=a); Y=b)) » |HBI » B (X^l, one(X, Y)) » |BBI * nil} 

-o exit (one(X, Y),two(X, Y)) . {post(X, Y) • l/post(X, Y), fail • mi} , {B y ((Y=a; Y=b), two(l, Y)) . Oi?,(Y=a, (l/(Y=a); Y=b)) • l^^l . B y (X=l, one(X, Y)) . I^ffll • ni!} 

exit post(X,Y), {l/post(X, Y), fail, nii} , {By((one(X. Y), two(X, Y)). post(X, Y)) « B y ((Y=a; Y=b) , two(l, Y)) « OR{Y=a, (l/(Y=a); Y^b)) » |BEI * By(X=l, one(X, Y)) » |BBI »™'} 
-o call fail , {2/post(X, Y),fail« mi} , {By((one(X, Y), two(X, Y)), post(X, Y)) • B y ((Y=a: Y=b) , two(l, Y)) • Ofl(Y=a, (l/(Y=a); Y=b)) » |BEI « By(X=l, one(X, Y)) » |BBI « nil} 
-o fail fail , {2/post(X,Y), fail* ni/} , {By((one(X, Y), two(X, Y)), post(X, Y)) • By ((Y=a; Y=b), two(l, Y)) • Ofl(Y=a, (l/(Y=a); Y=b)) « |HEI « By (X^l, one(X, Y)) » |BB| » mi} 

redo po5t(X, Y) , {l/post(X, Y), fail • ni/} , {By((one(X, Y), two(X, Y)), post(X, Y)) • B y ((Y=a: Y=b) , two(l, Y)) > Ofl(Y=a, (l/(Y=a); Y=b)) « |HEI « By(X=l, one(X, Y)) » |BBI *™U 
-o redo (one(X, Y),two(X, Y)) , {post(X, Y) . l/po5t(X, Y), fail . mi} , {By ((Y^a; Y=b), two(l, Y)) » OB.(Y=a, (l/(Y=a): Y=b)) » |HBI » B y (X^l, one(X, Y)) » |BBI » nil} 
-o redo two(X,Y), {2/one(X, Y) , two(X, Y) . post(X, Y) . l/post(X, Y) , fail . nii} . {By ((Y=a; Y^b), two(l, Y)) » Ofl(Y=a, (l/(Y=a): Y^b)) » |HBI » By (X^l, one(X, Y)) «|BBI»™'} 



-o redo (Y=a;Y=b), {two(l, Y) • 2/one(X, Y), two(X, Y) . po5t(X, Y) . l/post(X, Y) Jail • mi} , {Ofi(Y=a, (l/(Y=a); Y^b)) « |i3EM » BY(X=1, one(X, Y)) t ttatSt * nil} 
-o redo Y=a, {(l/(Y=a): Y=b) • two(l, Y) . 2/one(X, Y) , two(X, Y) . post(X, Y) • l/po5t(X, Y) , fail • nii} , { |HBI « BY (X^l, one(X, Y)) « |BB| «mi} 

faiiy=a. {(l/(Y=a);Y=b).two(l,Y).2/one(X,Y),two(X,Y)«post(X,Y).l/po5t(X,Y),fail.mi} . {By(X=l, one(X, Y)) « |BE| » mi> 

ca« Y=b, {(2/(Y=a);Y=b)«two(l,Y)»2/one(X,Y),two(X,Y)»po5t(X,Y).l/post(X,Y),fail.mi} , jBYjX^l, one(X, Y)) » |5B1 * nil} 

eaiit Y=b, {(2/(Y=a): Y=b) . two(l, Y) . 2/one(X, Y) , two(X, Y) . post(X, Y) • l/po5t(X, Y) , fail . nii} , { |HEI « BY (X^l, one(X, Y)) « |BB| «mi} 
-o esif (Y=a;Y=b), {two(l, Y) . 2/one(X, Y) , two(X, Y) . post(X, Y) . l/po5t(X, Y) , fail • mi} , {Oi?.(Y=b, (2/(Y=a) ; Y^b)) « |HBI » B y (X=l, one(X, Y)) « |BBI «™U 
-o e2;it two(l, Y) , {2/one(X, Y) , two(X, Y) • post(X, Y) < l/po5t(X, Y) Jail . mi} , {By((Y=a: Y=b), two(l, Y)) > Ofl(Y=b, (2/(Y=a); Y=b)) » |HBI » By(X=l, one(X, Y)) » |5B| »mi} 
-o exit (one(X, Y),two(X, Y)) . {post(X, Y) • l/post(X, Y) , fail • mi} , {B y ((Y=a; Y=b), two(l, Y)) . Oi?,(Y=b, (2/(Y=a); Y=b)) . I^^H • B Y(X=1, one(X, Y)) • ^^B|» mi} 

exit post(X,Y). {l/post(X,Y),fail«mi} , {B Y((one(X, Y) , two(X, Y)), po5t(X, Y)) . B y ((Y=a; Y=b) , two(l, Y)) . Oi?,(Y=b, (2/(Y=a) ; Y=b)) • l^^l • B y (X=l, one(X, Y)) • l^ffll • nii} 
-o call fail, {2/post(X,Y),fail«mi} , {B y ((one(X, Y) , two(X, Y)) , post(X, Y)) . B y ((Y=a: Y=b) , two(l, Y)) . Ofl(Y=b, (2/(Y=a) ; Y^b)) « |HEI « B y (X^l, one(X, Y)) » |BBI * ™U 
-o fail fail , {2/post(X, Y),fail» rii/} , {By((one(X, Y), two(X, Y)), post(X, Y)) > By((Y=a; Y=b), two(l, Y)) > Ofl(Y=b, (2/(Y=a): Y^b)) » IHBI « BY (X=l, one(X, Y)) « |BBI « nil} 
^ redo po5t(X, Y) , {l/post(X, Y), fail • ni/} , {By ((one(X, Y), two(X, Y)), post(X, Y)) • B y ((Y=a; Y=b) , two(l, Y)) • Ofl(Y=b, (2/(Y=a); Y=b)) » IHBI » B y (X^l, one(X, Y)) » |BB1 « ™U 
-o redo (one(X, Y),two(X, Y)) , {post(X, Y) • l/post(X, Y) , fail • nii} , {By ((Y=a; Y=b), two(l, Y)) . Ofl(Y=b, (2/(Y=a): Y=b)) • l^ffil • By (X=l, one(X, Y)) • l^ffll • mi} 
-o redo two(X, Y) , {2/one(X, Y) , two(X, Y) • post(X,Y) • l/post(X, Y) , fail . ni/} , {By ((Y=a; Y=b), two(l, Y)) « Ofl(Y=b, (2/(Y=a) ; Y^b)) « KflBI « By (X=l, one(X, Y)) « |BBI « ™'} 
-K redo (Y=a;Y=b), {two(l, Y) • 2/one(X, Y), two(X, Y) . po5t(X, Y) . l/post(X, Y) Jail • mi} , {Ofl(Y=b, (2/(Y=a); Y^b)) « |HBI « By(X=l, one(X, Y)) » |BBI * ™U 
-K redo Y=h, {(2/(Y=a); Y=b) . two(l, Y) . 2/one(X, Y)jwo(X, Y) . post(X, Y) . l/po5t(X, Y), fail . nii} , { |BBI » By(X=l, one(X, Y)) « |5BI « ™'} 
-o failY=h, {(2/(Y=a);Y=b)»two(l,Y).2/one(X,Y)jwo(X,Y).post(X,Y).l/po5t(X,Y)Jail«nii} , {By(X=l, one(X, Y)) « |BB| « nii > 

/aii (Y=a;Y=b), {two(l, Y) • 2/one(X, Y) , two(X, Y) . po5t(X, Y) . l/post(X, Y), fail • mi} , {B y (X^l, one(X, Y)) » |5E| » mi} 
-o /aii two(l, Y) , {2/one(X,Y),two(X,Y).post(X,Y).l/post(X,Y)Jail.mi} , {By(X=l, one(X, Y)) « |BB| «mi} 
-o redo one(X,Y) . {l/one(X, Y)Jwo(X, Y) . post(X, Y) . l/po5t(X, Y), fail . nii} , {By(X=l, one(X, Y)) » |BBI » ™'} 
-» redoX=l, {one(X, Y) . l/one(X, Y) , two(X, Y) . post(X, Y) • l/po5t(X, Y) Jail • nii} , { |5BI »™'> 
-o fail X=l, {one(X,Y)«l/one(X,Y)Jwo(X,Y)«po5t(X,Y)«l/po5t(X,Y)Jail.mi} . {nii} 
-» /aii one(X,Y), {l/one(X, Y)jwo(X, Y) • post(X, Y) . l/post(X, Y) Jail . nii} , {nii} 
-o /aii {one(X, Y) Jwo(X, Y)) . {post(X, Y) . l/post(X, Y) Jail . nii} , {nii} 
-» /aii post(X.Y), {l/post(X,Y)Jail« nii} , {nil} 
-t. fail (post(X, Y) Jail) , {nii} , {nil} 



Table 2. Execution of a query in S:PP 



